Method and devices for controlling retransmissions in data streaming

ABSTRACT

In a method for the transmission of a plurality of data packets from a sender ( 1 ) to a receiver ( 2 ), the data transmission is performed over a link ( 5 ) with a transmission capacity having a limit. A presentation time is defined for a first data packet of said plurality, and the receiver ( 2 ) performs a first check whether data packets are correctly received. At least one data packet is selected for retransmission according to the result of the first check. In the method, a delay budget (DB) is determined from the presentation time of the first data packet. Furthermore, a delay requirement is determined for the retransmission of the selected data packet from the limit of the transmission capacity and from the transmission capacity required for the selected data packet. A comparison ( 30 ) of the delay requirement and the delay budget (DB) is performed, and the retransmission is executed for the selected data packet according to the result of the comparison ( 30 ). Devices and software programs for executing the method are also described.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to streaming data between a sender and areceiver in a network over a link with a defined transmission capacity.

BACKGROUND OF THE INVENTION

Streaming applications are getting increasingly important, both in fixednetworks like the Internet and in the context of 3^(rd) Generationmobile networks like UMTS (Universal Mobile Telephone System). Streamingtechnology allows a nearly instantaneous access for the users topre-stored content without the necessity to transfer a complete filebefore presentation. Streaming applications are widely used for videoand audio media.

In a streaming application, a stream of data packets is transmitted froma server being the original sender to a client as final receiver of thedata packets. Packets may be lost during the transmission, e.g. due totransmission errors or due to dropping by congestion avoidance methods.Packets may also be delayed, for example due to link characteristics,link congestion and retransmissions of lost packets. Differentindividual delays for the packets result in a delay jitter within thepacket stream. The data rate of a stream can also have variations due tothe encoding of the media. For example, one option to transmit a videosequence is the transmission of differences between consecutive images.This leads to a high data rate in case of many differences while thedata rate is low if several consecutive images are identical.

Each packet has a presentation time at which it must be available at theclient for processing and presentation, e.g. for display in a video oraudio sequence. Packets, which are lost or arrive too late, cannot beplayed out. As a consequence, streaming applications are sensitive bothagainst packet loss and delays. Therefore, streaming clients generallyhave a buffer, which allows to compensate transmission delay jitter andthe delay introduced by the retransmission of lost or erroneous datapackets. Both the client memory required for buffering and the linkbandwidth are however limited and expensive resources, especially inmobile applications. Therefore, they are often selected close to theminimum requirements for a desired quality of service.

The RTP (Real-Time Transport Protocol) protocol allows an efficientdelivery of data packets for real-time media like audio or video files.RTP is transported on UDP (User Datagram Protocol), which does notinclude a retransmission mechanism for the recovery of lost or corruptedpackets. Therefore, a retransmission mechanism on top of RTP is requiredto compensate packet losses. The RTCP (RTP control protocol) specifies adata packet format that can be used to implement such a retransmissionmechanism. The retransmission control method is not specified in RTCP toallow adaptations to individual applications. Different retransmissioncontrol methods for the RTP protocol are therefore possible based on theRTCP data packet format.

One example of a retransmission method is described in U.S. Pat. No.6,275,471 When a receiver receives a stream from a sender after anaccording request, the receiver checks whether there are any lost datapackets. If this is the case, the receiver determines a remainingtransmission period for the lost data packet, i.e. the latest time atwhich the packet needs to be available at the receiver for presentation.The remaining transmission period is sent with the negativeacknowledgement for the lost data packet to the sender. The sendercompares the remaining transmission period with an estimated round-triptime to check whether the requested packet can arrive at the receiverbefore the required presentation time. If this is the case, theretransmission is performed. Else, the packet is not retransmitted andthe receiver constructs the output of the application without the lostpacket, e.g. by using error concealment techniques.

Between the server and the client, the data packets are transported byone or several transport networks, typically over a plurality of linkswith different characteristics. Often, one of said links is a bottleneckfor the transmission as it has the lowest data rate and/or a high roundtrip time, the latter influencing especially the delay ofretransmissions. In wireless communication systems, the bottleneck isgenerally the wireless link to a mobile user equipment, e.g. a mobilephone. European application EP 1 130 839 describes an option tocalculate the transmission delay of data packets.

On a link with limited bandwidth, self-congestion may occur. If datapackets are retransmitted, the server has to ensure that the totaltraffic comprising both original packets and retransmitted data packetsdoes not exceed an allowed or guaranteed bitrate. Due to the limitation,original data packets are often delayed when a retransmission isperformed, especially if the data rate of the original data packets isclose to the link capacity. This delay can disturb the presentationbehavior of the data stream by the streaming application, which may beinterrupted or may need to apply error correction or concealment.

The data rate may vary considerably for some types of links, e.g.according to the behavior of other users sharing the same resources,while other links provide a constant or nearly constant bandwidth fortransmission. For example, UMTS streaming bearers transporting the datapackets to mobile clients can be negotiated for specific combinations ofguaranteed bitrate, packet loss, and delay for the data packets. Manystreaming applications allow an adaptation of the stream to guaranteedparameters, e.g. by selecting the rate of original data below theguaranteed bitrate, allowing a rate of retransmissions according to thedifference of selected and guaranteed bitrate. A gateway, e.g. a 3G-GGSN(Gateway GPRS Support Node) in the example of a UMTS system, controlsthe traffic from the server to the client using a traffic policingfunction. If the traffic exceeds the guaranteed parameters, packets canbe dropped. This can lead to a severe disturbance of the streampresentation, especially if retransmissions increase the bitrate of thestream beyond a guaranteed bitrate.

SUMMARY AND DESCRIPTION OF THE INVENTION

It is an object of the present invention to obviate the abovedisadvantages and provide a method and devices for controllingretransmissions in data streaming which reduce the disturbance of thereceiving application by delayed or dropped data packets. It is afurther object, to allow a high utilization of the available bandwidthfor the transmission. It is still another object to perform theretransmission control with low complexity.

In a method for the transmission of a plurality of data packets from asender to a receiver, the data transmission is performed over a linkwith a limited transmission capacity. Sender and receiver need not to bethe origin and final destination of the transmission but may also beintermediate entities, e.g. proxies. The method can most easily beimplemented if the limit of the transmission capacity is constant or ifchanges in the limit can easily be predicted, e.g. due to slowvariations or information from other protocol entities in thetransmission.

The receiver performs a first check whether data packets are correctlyreceived. For example, the receiver can check whether packets arecompletely missing by using packet sequence numbers or it can determinefrom redundant information in the data packet, e.g. from a CRC (cyclicredundancy check), whether a packet is erroneous due to transmissionerrors. At least one data packet is selected for retransmissionaccording to the result of the first check, i.e. the packet is selectedif it is erroneous or missing.

A presentation time is defined for a first data packet of saidplurality. Typically, the plurality of data packets for transmission isa packet stream although the method is generally applicable if apresentation time is defined for packets transmitted over a link. Thepresentation time corresponds to the latest time when the first datapacket must arrive at the receiver to be processed and, in case of thefinal receiver in a transmission, presented by the application. Thepresentation time can for example be indicated in a data field in aprotocol header of said packet or in control information sent with astream. In most cases, presentation times are defined for all datapackets in the plurality.

Throughout this specification, packets transmitted for the first timeare denoted original packets. Original packets and retransmissions arenot necessarily identical, e.g. if a protocol allows to retransmit onlythose sections of an original packet which were erroneous. It is alsopossible, that a retransmission is detected as missing or erroneous andselected for a further retransmission. Both the first data packets andthe selected data packet can therefore be an original transmission or aretransmission.

From the presentation time of the first data packet, a delay budget isdetermined. The delay budget indicates a transmission capacity, whichcan be attributed to retransmissions without delaying the first datapacket beyond the presentation time. Furthermore, a delay requirement isdetermined for the retransmission of the selected data packet. The delayrequirement is calculated from the limit of the transmission capacityand from the transmission capacity required for the selected datapacket, i.e. the delay requirement is calculated under the assumptionthat the retransmission is performed using the limit of the transmissioncapacity.

A comparison of the delay requirement and the delay budget is performed.The retransmission of the selected data packet is executed according tothe result of the comparison, i.e. the selected data packet is onlyretransmitted if the delay budget is at least equal to the delayrequirement while the retransmission is else cancelled.

Typically, the limit of the transmission capacity corresponds to amaximum data rate. However, other or further resources relating to thetransmission capacity can be considered in the comparison, e.g.processing capacities of the sender or the receiver. The delayrequirement generally corresponds to a packet size of the selected datapacket. The comparison with the delay budget is in this case preferablyperformed for the packet size divided by the limit of the transmissionrate.

Although the method and the involved comparison are described throughoutthis specification according to the time required for transmission, itshould be noted that equivalent representations exist. For example, incase of a constant data rate, it is equivalent to determine the delaybudget as an allowable number of data blocks of a lower protocol layeror bytes or bits and compare the size of the selected data packets tothe delay budget determined in this way.

The basic idea of the proposed method is a retransmission control, whichavoids the problem of self-congestion caused by retransmissions whentransmitting over a bottleneck link. The method avoids buffer underflowswhile allowing an implementation with low complexity. It is especiallysuitable for data streaming like it is performed for example in mobilemultimedia applications. For this case, the method takes advantage ofthe fact, that a variable rate encoded stream does not always utilizethe full capacity of the link. Especially, the perceived quality of theapplication output is considerably improved because interruptions of thedata stream are avoided. The method may be implemented in the server orin the client. To improve the performance on a connection, one option isto divide it on one or both ends of a bottleneck link by a proxy. Inthis case, it can also be advantageous to implement the method in theproxy being an intermediate sender and receiver in the datatransmission.

In a preferred embodiment of the method, the receiver stores datapackets in a buffer with a buffer fill level varying over time. In thiscase, the delay budget is a function of the buffer fill level andcalculated with respect to the buffer fill level. A buffer generally hasa predetermined buffer size corresponding to the maximum fill level andthus to the maximum delay budget. Preferably, the transmission iscontrolled in such a way that the fill level is close to the buffer sizein order to maximize the delay budget.

Preferably, the delay budget is determined for several first datapackets, i.e. for a group comprising at least two first data packets. Inthis way, the delay budget can consider all first data packets, whichmay be delayed by the retransmission of the selected data packet. Onesimple option in this case is to calculate first an individual-delaybudget for every first data packet in the group and determine then thedelay budget as the minimum of the individual delay budgets.

The delay budget preferably considers the presentation times for allfirst data packets, which may be delayed by retransmissions. On theother hand, the processing effort increases with the number of datapackets in the group considered for the delay budget. If the first datapackets are transmitted in a predefined sequence, it is thereforeadvantageous to select only those data packets for the group ofconsidered packets, which are the next data packets for transmission insaid sequence. Either a certain number of packets can be considered or acriterion is defined for stopping the selection. An advantageousstopping criterion is to finish the selection of data packets for thegroup if the delay budget will remain constant for any further packets.For a limited buffer size, it is generally possible to stop thecalculation of the delay budget without loss of information when thetransmission of the packets in the group at the limit of thetransmission capacity reaches the limited buffer size. Consideration offurther data packets does not affect the delay budget and the selectionof data packets for the group can therefore be stopped.

The method is advantageous if the receiver requests the selected datapackets in a status message. In this case, the method can either beimplemented in the receiver to control the sending of status messages orin the sender to control whether and which retransmissions are performedin reply to a status message.

When the method is used, several data packets can be selected forretransmission, i.e. the selected data packet and at least one furtherdata packet. Therefore, the delay budget is preferably reduced by thedelay requirement if a retransmission of a data packet is performed. Thereduction allows a simple adaptation of the delay budget for furthercomparisons relating to the further data packets selected forretransmission. In this case, a new delay budget is only calculated fromthe presentation times of the first data packets if the adapted delaybudget is not sufficient for a further delay requirement. Alternatively,a new delay budget can be calculated from the presentation times of thefirst data packets for every further comparison. However, the latterapproach generally requires more processing capacity.

If the delay budget is adjusted according to the performedretransmissions, it is advantageous to perform a further calculation ofthe delay budget from the presentation times of the first data packetsafter a further comparison of the delay budget with a further delayrequirement. This allows a reduction of the processing effort fordetermining a delay budget for any further retransmissions.

Generally, the calculation of the delay budget assumes that data istransmitted at the limit of the transmission capacity. However, thepresent data rate may be subject to further constraints, e.g. temporaryconstraints by the transmission system due to prioritized traffic or dueto a lower transmission rate by the sender to accommodate for a limitedbuffer size of the receiver. Therefore, the delay budget is preferablyadapted if a present rate of the data transmission is lower than thelimit of the data transmission capacity.

It is possible to extend the method by utilizing additional informationabout the data packets to optimize the overall performance of theapplication in the presence of packet losses. For this purpose, apriority is preferably attributed to a first or selected data packet andthe retransmission is executed according to said priority. For example,information affecting the presentation of a high number of subsequentframes may have a higher priority in a streaming application. Thepriority may be considered in different steps of the method, e.g. it canbe considered in the first check, in the determination of the delaybudget, in the determination of the delay requirement, in the comparisonof delay requirement and delay budget, or for initiating aretransmission. For example, it can be avoided that an originaltransmission with low priority blocks a retransmission with highpriority by setting the delay requirement for the retransmission to zeroor by omitting packets with low priority from the calculation of thedelay budget. In another example, a retransmission of a packet with lowpriority can both be avoided by not selecting it in the first check andby skipping the execution of the retransmission after the comparison. Inthe comparison, adjusting parameters can be used according to thepriorities. This embodiment of the method is especially advantageous ina server because the priorities need not to be transmitted to thereceiver in this case.

If priorities are specified according to the application content, it canalso be indicated that packet losses are more acceptable at certainpositions in a data stream, e.g. at scene cuts or during still images ofa video. It is then possible to skip the proposed method for packetssufficiently close to the acceptable position, e.g. by setting the delayrequirement for all those data packets to zero, which are closer to theacceptable position than one or two round trip times of thetransmission. In this way unavoidable losses and re-buffering events canbe shifted to positions in the packet stream for which the impact on theperceived quality is minimized.

Preferably, in a further check a presentation time for the selected datapacket is compared to an estimated arrival time of the selected datapacket at the receiver. The retransmission of the selected data packetis performed according to the result of the further check.Correspondingly, retransmissions of those data packets can be avoided,which would arrive too late at the receiver for processing.

A preferable sender for the transmission of a plurality of data packetsto a receiver has a transmission unit for sending the data to thereceiver. The data transmission can be performed over a link with atransmission capacity having a limit. Furthermore, the sender has areceiving unit for receiving an indication whether the receiver didcorrectly receive the data packets. A processing unit is connected tothe transmission unit and the receiving unit, typically integrated in atransceiver, and processes transmitted and received data packets.Especially, the processing unit can define a presentation time for afirst data packet of said plurality, e.g. by extracting a correspondingdata field from a header of the first data packet. In addition, theprocessing unit can select at least one data packet for retransmissionaccording to a received indication.

From the presentation time of the first data packet, the processing unitdetermines a delay budget. Furthermore, the processing unit determines adelay requirement for the retransmission of the selected data packetfrom the limit of the transmission capacity and from the transmissioncapacity required for the selected data packet. The processing unit isadapted to perform a comparison of the delay requirement and the delaybudget and to initiate the retransmission for the selected data packetaccording to the result of the comparison, i.e. to initiate it only ifthe comparison indicates a sufficient delay budget for theretransmission.

A receiver for the reception of a plurality of data packets from asender has a reception unit for receiving the data packets. The datapackets are transmitted over a link with a transmission capacity havinga limit. A transmission unit of the receiver can send indicationswhether data packets are correctly received. A processing unit isconnected to the transmission unit and the reception unit, performs acheck, whether data packets are correctly received, and selects at leastone data packet for the indication according to the result of saidcheck. The processing unit is also adapted to define a presentation timefor a first data packet of said plurality.

In addition, the processing unit is adapted to determine a delay budgetfrom the presentation time of the first data packet. The processing unitalso determines a delay requirement for the retransmission of theselected data packet from the limit of the transmission capacity andfrom the transmission capacity required for the selected data packet.The processing unit performs a comparison of the delay requirement andthe delay budget and selects the data packet for the indicationaccording to the result of the comparison, i.e. a data packet is onlyincluded in the indication if it is both not correctly received and thedelay budget allows a retransmission.

Both the sender and the receiver may be adapted to any embodiment of theabove method. The method can also be implemented by a software programunit comprising code for performing the steps of the method whenexecuted in the processing system of a client, a server or a proxy. Theprogram unit is for example stored on a data carrier or loadable intothe processing system, e.g. as a sequence of signals. It may be part ofa software packet including further software units.

The foregoing and other objects, features and advantages of the presentinvention will become more apparent in the following detaileddescription of preferred embodiments as illustrated in the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a data transmission from a server to a client

FIG. 2 shows a buffer underflow caused by retransmissions when streamingover a bottleneck link

FIG. 3 shows a flow chart of a retransmission method according to theinvention

FIG. 4 shows the computation of the earliest sending time t_(n) for adata packet n

FIG. 5 shows an example of computing the delay budget forretransmissions

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

FIG. 1 depicts a data transmission from a server being the sender 1 ofthe data packets to a client being the receiver 2 for the sent packets.The transmission is performed over one or more links 3-5, which are forexample connections in a communication system. Typically, one of thelinks is a bottleneck link 5 with a low rate of data transmission.Optionally, the performance of the transmission is improved by one ortwo proxies 6, 7 at the ends of the bottleneck link 5. In this case, theproxies 6, 7 can be intermediate senders and receivers in thetransmission.

The sender 1 has a memory M, in which the content for transmission isstored and from which it is retrieved and processed by a processing unitPS before transmission to the receiver 2 by a transceiver unit TRS. Alsothe receiver 2 is provided with a transceiver unit TRR for decoding thereceived data packets and forwarding them to a processing unit PR, whichprocesses the content for presentation to a user. A buffer BU in thereceiver allows a temporary storing of the content to compensate forvariations in the transmission rate. According units can also processthe data in the optional proxies 6, 7 and are omitted in the figure onlyfor simplification.

FIG. 2 illustrates the underlying problem of a protocol performingretransmissions over a link with limited bandwidth. The figurerepresents the accumulated data, i.e. the total number B of bytes,transmitted over time t. Presentation line 11 corresponds to the totalamount of data, which needs be transmitted to the receiver at any timeto allow a smooth presentation of the media. If less data is availableat a certain time, i.e. in case of a client buffer underflow, no data ispresent for the continuous presentation. The presentation has to stopuntil further data is transmitted and available, i.e. until are-buffering took place.

Generally complete data packets are processed and forwarded forprocessing to the application. Therefore, presentation line 11corresponds to a sequence of discrete points in time when the last datablock of every packet has to be available at the receiver. Forsimplicity of representation, these points are represented by theconnecting presentation line 11.

A streaming client usually buffers more data than required for smoothpresentation to be able to compensate small fluctuations in the linkthroughput. Normally, the available buffer space is limited, especiallywhen memory is expensive as it is the case in mobile terminals. Theupper limit 12 in the amount of data, which can be stored by the client,is shown in FIG. 2 by a broken line. Upper limit 12 is a verticallyshifted copy of the presentation line 11. The shift between presentationline 11 and upper limit 12 corresponds to the buffer size. Data has tobe discarded in case of a buffer overflow, i.e. if the client, due tolimited buffer size, cannot store data transmitted by the sender.

To avoid both a buffer underflow and an overflow, the server sends thedata packets according to a transmission plan 13, which is calculated tokeep the accumulated data between presentation line 11 and upper limit12. As long as the data follows the transmission plan 13, neither abuffer underflow nor a buffer overflow occurs. The server can determinethe transmission plan 13 because both the client buffer size and thepresentation line 11 are known. The client buffer size is oftennegotiated during session setup while presentation line 11 is a functionof the content stored at the server. Preferably, the transmission plan13 corresponds closely to the upper limit 12 of the buffer to allow fortransmission variations or a temporary link disruption, especially forwireless transmission.

Due to retransmitted packets, the scheduling of the original data can bedelayed. This is indicated in FIG. 2 by doted line 14. During thehorizontal section of line 14, the transmission of original data packetsis suspended and retransmissions are performed instead. The delay maycause an immediate buffer underflow or it may result in an underflow Uat a later time. This is due to the fact that the maximum transmissionrate, corresponding to the maximum slope of transmission plan 13, islimited. Presentation line 11 may have temporarily a steeper slope thanthe maximum transmission rate and the transmission of a consecutive datapacket may still be incomplete at presentation time. In this case, datapackets arrive at the client after the required presentation time.

The proposed method allows to avoid disturbances by retransmissions,especially buffer underflows and according re-buffering events, whenstreaming over a bottleneck link. The basic idea is a prediction of thefuture transmission behavior, which allows the server to retransmitpackets only in those cases, in which the retransmission does not resultin an immediate or future buffer underflow. In particular, the describedmethod allows an implementation with low complexity at the server. Thisis especially advantageous for the processing of high data volumes andincreases the number of streams, which the server can processsimultaneously.

FIG. 3 shows an example of the retransmission control method. For theretransmissions, a delay budget is computed and managed. The delaybudget indicates the amount of time by which original data packets canbe delayed without resulting in a buffer underflow, i.e. whether aparticular retransmission will cause a buffer underflow.

The flowchart illustrates an implementation of the method in the server.In selection 22, a data packet is selected for retransmission, e.g.according to a request received from the client. After selection 22 of apacket, an optional check 24 is performed whether the retransmission canarrive at the client before the presentation time required for thescheduled presentation by the client application. Preferably, aretransmission is only performed if the check 24 indicates that thelatest presentation time is later than the estimated time for sendingout the retransmission plus the time required for the transmissionprocedure. The presentation time can be indicated in the request forretransmission or may be determined according to the presentationinformation at the sender while the value of the required time fortransmission can be estimated, e.g. as a half measured round trip timebetween client and server, or it can be pre-configured. If theretransmission will not arrive in time, the processing for the selectedpacket is stopped. The transmission resources can then be used for otherpackets in the same stream, especially new original data packets, orthey may be used by other senders sharing the same resources.

For the selected data packet, a determination 26 of the delayrequirement for the retransmission is performed. In the embodiment ofFIG. 3, an update procedure 28 of the delay budget follows subsequently.In update procedure 28, a new delay budget is calculated according tothe presentation times of the next unsent data packets and the maximumdata rate as described in more detail below. After the update procedure28, a comparison 30 of the delay budget and the delay requirement isexecuted. If the delay budget is at least equal to the delayrequirement, i.e. sufficient for the retransmission, an initiation 32 ofthe retransmission and a reduction 34 of the delay budget by the delayrequirement of the retransmitted data packet are performed. Else theprocess is stopped without retransmission. The time of initiation 32 maydiffer from the actual transmission of the selected data packet, e.g. tothe scheduling of other data packets.

Any new calculation of the delay budget requires considerable processingeffort. In an advantageous alternative to the method depicted in FIG. 3,a first comparison between the delay budget and the delay requirement isperformed before an update procedure of the delay budget. If the lastcalculated delay budget is at least equal to the delay requirement, i.e.still sufficient for the retransmission, update procedure 28 is omittedand the initiation 32 of the retransmission as well as the correspondingreduction 34 of the delay budget is immediately performed. If the delaybudget is smaller than the delay requirement, update procedure 28 isexecuted and a further comparison 30 of the delay budget is performed.The retransmission is then initiated or omitted according to the resultof the further comparison. In spite of the repeated comparison of thedelay budget, this implementation is more efficient in most casesbecause said comparison requires a low processing effort.

Apart from the update procedure 28, it should be noted that also thesequence of several other steps in the above method may be altered. Forexample the sequence of initiation 32 and reduction 34 may be reversed,or the determination 26 of the delay requirement can be performed at anytime until comparison 30 is executed. Furthermore, although theflowchart describes the process for a single data packet, it is oftenmore preferable to select more than one data packet in step 22. In thiscase, the steps of the method must be repeated for every data packetexcept update procedure 28, which is preferably only repeated when acomparison 30 disallows a retransmission.

Alternative to an implementation in the server as described in FIG. 3,the method can be also implemented in the client if the informationnecessary to calculate the delay budget is transmitted to the client. Inthis case, the client compares delay budget and delay requirement beforeit requests a retransmission from the server. If a retransmission willcause a future buffer underflow, the retransmission request iscancelled, i.e. the request is not sent or the request is omitted from amessage requesting several packets. An implementation at the client hasthe advantage of a reduced complexity at the server, which generallyprocesses many data streams in parallel and therefore typically has amuch higher processing load. In addition less traffic is sent in uplinkdirection from client to server since unnecessary retransmissionrequests are avoided. A disadvantage of this solution is the requiredtransmission of information to the client, which needs to be performedat least in part prior to the start of the data packet transmission.This can increase the session setup delays. Furthermore, extensions toexisting protocols are required to allow transmission of suchinformation. The more advantageous alternative depends therefore on theprotocol and implementation.

A central part of the proposed method is the computation of the delaybudget. With respect to FIGS. 4 and 5, a preferable example for thecomputation of the retransmission delay budget is described. In thedescription, it is assumed that a stream is encoded at a variable rateand transmitted at a constant rate over a bottleneck link while the sizeof the client buffer is limited.

The transmission of a packet stream requires a scheduling for the datapackets, which ensures that neither the data rate of the bottleneck linknor the client buffer size is exceeded. Typically, the size of the datapackets can vary. Equation (1) specifies the time t_(n) at which anoriginal data packet n can be sent. t_(n) is determined by the timet_(n-1) at which the previous original data packet was sent, the datarate R of the bottleneck link in bits per second, and the size s_(n-1)of the previous packet in bytes, assuming 8 bits in a byte, as

$\begin{matrix}{t_{n} = {t_{n - 1} + {{\max\left( {\frac{8*s_{n - 1}}{R},\delta} \right)}.}}} & (1)\end{matrix}$δ is a function of the buffer size and denotes the waiting time requiredto avoid a buffer overflow. During waiting time δ, data needs to bescheduled at a lower rate than R. If this is not the case, i.e. if

${\frac{8*s_{n - 1}}{R} < \delta},$the client buffer exceeds its maximum unless data packets are delayed ordropped.

An example for this case is depicted in FIG. 4 showing the accumulateddata over time with presentation line 11′ and upper limit 12′ of thebuffer as described with respect to FIG. 2. When at time t_(n-1), datais transmitted at the capacity limit, the upper buffer limit 12′ will beexceeded starting from point 15 as indicated by broken line 16.Therefore, the scheduling of the next transmission time t_(n) is shiftedto time t_(n-1)+δ, i.e. the function max in equation (1) selects themaximum of

$\frac{8*s_{n - 1}}{R}$and δ.

A computation of a new delay budget at a given time t_(s) requires ananalysis of the future presentation behavior, i.e. of the presentationline, in comparison to the maximum data rate of the bottleneck link. Theanalysis is possible since all relevant information is available fromthe streaming application, in particular the latest presentation time ofthe subsequent original data packets. A new computation of the delaybudget is necessary when the current delay budget is not large enough toallow retransmissions of missing or erroneous data packets.

With respect to FIG. 5, the computation of the delay budget for aspecific time t_(s) is explained in more detail. The delay budget attime t_(s) assumes a maximum rate transmission plan 41, which schedulesdata at the maximum rate of the bottleneck link. The maximum ratetransmission plan 41 is then inserted into the graph such that ittouches the presentation line from above without intersecting it. InFIG. 5 this is the case at time t_(c). The horizontal distance betweenthe original transmission plan 43 at t_(s) and the maximum ratetransmission plan 41 is the delay budget DB by which the actualtransmission plan can be delayed in time without resulting in a futurebuffer underflow.

If the present transmission rate is lower than the maximum rate, anupdate of the delay budget is required. For example, between times t_(s)and t₁, the delay budget decreases compared to t_(s) since data istransmitted at a lower rate than the maximum data rate to avoid anoverflow of the client buffer, which is already filled to the upperlimit. Therefore, in this region the delay budget needs to be updatedcontinuously until a reduced delay budget DB′ is attained at time t₁. Incontrast, between times t₁ and t₂ the delay budget DB′ remains constantsince the original transmission plan 43 sends data at the maximum datarate to fill up free buffer space created by the presentation rateexceeding the maximum transmission rate in the interval before t_(c).Correspondingly, the distance between the original transmission plan 43and the maximum rate transmission plan 41 is constant. Between t₂ andt_(e) the delay budget needs again to be updated continuously since alsoin this region the original transmission plan is not transmitting atfull speed. The update procedure reduces the current delay budget by thedifference between actual and maximum transmission rate multiplied bythe duration of the lower transmission rate.

It should be noted that reductions of the calculated delay budget aftertime t₂ result from the fact that a new calculation of the budget isavoided to save the required processing effort. The actual delay budgetincreases again after time t_(c) because the presentation rate is lowerthan the maximum transmission rate. If, after time t_(c), theretransmission of a data packet requires a higher delay budget than thecalculated delay budget DB+, a new calculation of the delay budget asdescribed for t_(s) can be performed. This increases the delay budget tothe actual present value.

More formally, an update of the delay budget is required at time t_(n-1)if

$\frac{8*s_{n - 1}}{R} < \delta$with the variables as defined with respect to equation (1). In thiscase, the updated delay budget is

$\begin{matrix}{{delay\_ budget} = {{delay\_ budget} - \left( {\delta - \frac{8*s_{n - 1}}{R}} \right)}} & (2)\end{matrix}$

After a retransmission was sent, the delay budget needs to be reduced bythe delay caused by the retransmission, i.e. by the delay requirement.If s_(r) denotes the size of the retransmitted packet, the delayrequirement for the retransmission is

$\frac{8*s_{r}}{R}$and the delay budget needs to be updated according to

$\begin{matrix}{{delay\_ budget} = {{delay\_ budget} - {\frac{8*s_{r}}{R}.}}} & (3)\end{matrix}$

When the transmission plan 41 at maximum rate intersects the upperbuffer limit 44 at time t_(e), the calculation of the delay budget canbe stopped. Any data packet, which is transmitted after t_(e) can notinfluence the delay budget because the limited buffer does not allow ahigher buffer level.

Simulations of the proposed method were carried out with a variable rateencoded video stream having a mean data rate of 59 kbps and a bottlenecklink rate of 65 kbps for a client buffer size of 32 Kbytes and aninitial buffering time of 1.7 sec. A network round-trip-time of 400 mswas assumed. The parameters allow a smooth playback of the applicationunder customary operating conditions.

Retransmission Control Number Lost Sent Retransmissions of pack-retrans- delivered Delayed packets ets missions in time packets State ofthe art 782 78 47 47 51 Proposed 782 78 45 45 0 method

The table compares the proposed retransmission mechanism compared with amethod according to the state of the art. In both cases 78 of 782transmitted packets were lost, corresponding to a packet lossprobability of approximately 10%.

The retransmission mechanism according to the state of the artretransmits 47 of the 78 lost packets, all of them arriving at theclient in time. The remaining, packets are not retransmitted as theywould arrive too late. However, since self-congestion is not taken intoaccount, 51 original packets of the data stream arrive at the client toolate, being delayed by the retransmissions. The delayed packets cannotbe used for the presentation and are dropped.

The present method retransmits 45 of the lost packets, all of themarriving in time. Due to the analysis of the impact of theretransmissions on the future presentation behavior, no packets of theoriginal data are delayed beyond the presentation time. It should benoted that the number of retransmissions is only marginally smallercompared to the state of the art because unnecessary transmissions oforiginal packets are totally avoided. As a result, only a total of 33data packets are lost to the application while in the state of the art82 packets, i.e. 51 delayed original packets and 31 delayedretransmissions, are lost for the application.

The above embodiments admirably achieve the objects of the invention.However, it will be appreciated that departures can be made by thoseskilled in the art without departing from the scope of the inventionwhich is limited only by the claims.

1. A method comprising a server for retransmitting a plurality of datapackets from a sender to a receiver in a telecommunications network,wherein the data transmission is performed over a link having limitedtransmission capacity, and a presentation time is defined, for a firstdata packet of said plurality, as corresponding to the latest time whenthe first data packet of said plurality must arrive at the receiver tobe processed and presented by an application, wherein the receiverperforms a first check whether data packets are correctly received andselects a further data packet for retransmission according to the resultof the first check; determining a delay budget from the presentationtime of the first data packet, the delay budget indicating atransmission capacity available for data packet retransmissions withoutdelaying the first data packet beyond the presentation time; determininga delay requirement for the retransmission of the selected data packetfrom the limit of the transmission capacity and from the transmissioncapacity required for the selected data packet; comparing the delayrequirement and the delay budget; and retransmitting the selected datapacket if the delay budget is at least equal to the delay requirement,otherwise cancelling the retransmission of the data packet.
 2. Themethod according to claim 1, wherein the receiver stores data packets ina buffer with a buffer fill level and wherein the delay budget is afunction of the buffer fill level.
 3. The method according to claim 1,wherein the delay budget is determined from the presentation times foreach of a group comprising at least two first data packets.
 4. Themethod according to claim 3, wherein the at least two first data packetsof the group are to be transmitted in a predefined sequence, and whereinadditional data packets are to be added to the group, which are the nextdata packets for transmission in the predefined sequence, and whereinthe adding of additional data packets to the group is stopped if thedelay budget is expected to remain constant for further additionalpackets.
 5. The method according to claim 1, wherein the receiverrequests retransmission of the at least one data packet in a statusmessage transmitted to the sender.
 6. The method according to claim 1,wherein the delay budget is reduced by the delay requirement if aretransmission is performed.
 7. The method according to claim 6, whereina further comparison of the delay budget with a further delayrequirement is performed before a further calculation of the delaybudget.
 8. The method according to claim 1, wherein the delay budget isupdated if a present rate of the data transmission is lower than thelimit of the data transmission capacity.
 9. The method according toclaim 1, wherein a priority is attributed to the at least one selecteddata packet and wherein the retransmission is executed according to saidpriority.
 10. The method according to claim 1 wherein a presentationtime for the at least one selected data packet is compared to anestimated arrival time of the selected at least one data packet at thereceiver in a further check, and wherein the retransmission of theselected at least one data packet is performed according to the resultof the further check.
 11. The method of claim 1, wherein the delaybudget is computed ast _(n) =t _(n-1)+max(8*s _(n-1),σ)/R; where t_(n) is when an originaldata n can be sent and is determined by the time t_(n-1) at which theoriginal data packet n was sent, R is the data rate of a bottleneck linkin bits per second, and size s_(n-1) of the previous packet in bytes andσ denotes waiting time required to avoid buffer overflow.
 12. The methodof claim 1, wherein the delay budget indicates the amount of time bywhich the first data packet can be delayed without resulting in a bufferunderflow.
 13. A sender in a network for transmitting a plurality ofdata packets to a receiver, the sender comprising: a transmission unitfor transmitting data over a link having a limited transmissioncapacity; a means for receiving an indication whether data packets arecorrectly received by the receiver; and a processing unit for: defininga presentation times, for a first data packet of said plurality, ascorresponding to the latest time when the first data packet of saidplurality must arrive at the receiver to be processed and presented bythe application, and selecting a data packet for retransmissionaccording to the indication; determining a delay budget from thepresentation time of the first data packet, the delay budget indicatinga transmission capacity available for data packet retransmissions,without delaying the first data packet beyond the presentation time;determining a delay requirement for the retransmission of the selecteddata packet from the limit of the transmission capacity; performing acomparison of the delay requirement and the delay budget; andretransmitting the selected data packet if the delay budget is at leastequal to the delay requirement, otherwise cancelling the retransmissionof the data packet.
 14. The sender of claim 13, wherein the delay budgetis computed ast _(n) =t _(n-1)+max(8*s _(n-1),σ)/R; where t_(n) is when an originaldata n can be sent and is determined by the time t_(n-1) at which theoriginal data packet n was sent, R is the data rate of a bottleneck linkin bits per second, and size s_(n-1) of the previous packet in bytes andσ denotes waiting time required to avoid buffer overflow.
 15. A receiverin a network for the reception of a plurality of data packets from asender, the receiver comprising: a reception unit for receiving theplurality of data packets over a link having a limited transmissioncapacity; a transmission unit for sending an indication whether datapackets are correctly received; and a processing unit for: determining apresentation time, as corresponding to the latest time when the firstdata packet of said plurality must arrive at the receiver to beprocessed and presented by the application, of a first data packet to betransmitted over the link with a limited transmission capacity,performing a check of whether data packets are correctly received,determining a delay budget from the presentation time of the first datapacket, the delay budget indicating a transmission capacity availablefor data packet retransmissions without delaying the first data packetbeyond the presentation time; determining a delay requirement forretransmission of a selected data packet from the limit of the link'stransmission capacity and from the transmission capacity required forthe selected data packet, performing a comparison of the delayrequirement and the delay budget, and retransmitting the selected datapacket if the delay budget is at least equal to the delay requirement,otherwise cancelling the retransmission of the data packet.
 16. Thereceiver of claim 15, wherein delay budget is computed ast _(n) =t _(n-1)+max(8*s _(n-1),σ)/R; where t_(n) is when an originaldata n can be sent and is determined by the time t_(n-1) at which theoriginal data packet n was sent, R is the data rate of a bottleneck linkin bits per second, and size s_(n-1) of the previous packet in bytes andσ denotes waiting time required to avoid buffer overflow.